Many Web Services Applications have utilized complex XML (eXtensible Markup Language) schema definitions to describe their data types. Generally, Web Services Applications exchange data in the form of XML messages that conform to a specific XML schema. XML is an industry-standard, system-independent way of representing data. Like HTML (HyperText Markup Language), XML encloses data in tags, but XML tags relate to the meaning of the enclosed text and XML is extensible. With XML, a user can write his/her own tags to describe the content in a particular type of document. Another aspect of XML's extensibility is that a user can create a schema to describe the structure of a particular type of XML document.
To work directly with an XML schema, programmers often have to work with the low-level XML APIs. In many cases, it is very inconvenient for programmers to use XML APIs such as Document Object Model (DOM) to develop their Web Services applications. It may be easier for Java programmers to deal with Java objects than XML content. Thus, when programmers develop the Web Services Applications, the XML schema types are mapped to appropriate Java types. One of the most popular open standards to define such a mapping is the JAX-RPC specification. However, due to the complexity of XML schemas, some XML schema types are either essentially un-mappable or very difficult to define mappings. For that un-mappable (thus not supported) schema type, JAX-RPC maps them to SAAJ SOAPElement. SAAJ is SOAP (Simple Object Access Protocol) with Attachment API for Java. SOAPElement is one interface defined by SAAJ to represent the raw XML data. Compared to Java class such as Java Bean class, the SOAPElement is a generic data structure that programmers can use to navigate the XML content using the SOAP Attachment API for Java (SAAJ) APIs. As such, mapping to the SOAPElement may be acceptable for certain data centric applications.
However, mapping to the SOAPElement may not be desirable for type centric applications because the SOAPElement deals with the raw SOAP message itself, not the predefined Java type. Further, the SOAPElement may not be the desirable choice even for data centric applications if programmers desire to maintain other data objects such as SDO (Service Data Object). Another problem may occur when programmers desire to define their own mapping rule. In such a case, the standard JAX-RPC mapping may not be applicable especially when programmers already have some legacy Java types suitable for mapping the schema type.
Therefore, it would be desirable to provide a pluggable custom data binding system which could be used to replace or extend the existing mappings for certain schema types. It would be also desirable to provide a custom data binding system which could be pluggable in various deployment scenarios such as server, application, even a web module or the like.